A LAN is a high-speed network (typically 10 to 1000 Mbps) that supports many computers connected over a limited distance (e.g., under a few hundred meters). Typically, a LAN spans a single building. U.S. Pat. No. 6,757,286 provides a general description of a LAN segment. A WAN, in contrast, is a data communications network that spans any distance and is usually provided by a public carrier (such as a telephone company or service provider). A Virtual Local Area Network (VLAN) is mechanism by which a group of devices on one or more LANs that are configured using management software so that they can communicate as if they were attached to the same LAN, when in fact they are located on a number of different LAN segments. VLANs are basically broadcast domains defined within switches to allow control of broadcast, multicast, unicast, and unknown unicast within a Layer 2 device. After a VLAN has been created, individual switch ports (also referred to as “access ports”) are assigned to the VLAN. These access ports provide a connection for end-users or node devices, such as a router or server. Note, however, that VLAN information is not normally passed between switches; that is, trunk lines are required to pass VLAN information between switches. Because VLANs are based on logical instead of physical connections, they are extremely flexible.
Virtual Private Network (VPN) services provide secure network connections between different locations. A company, for example, can use a VPN to provide secure connections between geographically dispersed sites that need to access the corporate network. An IP VPN is the foundation many companies use for deploying or administering value-added services including applications and data hosting network commerce, and telephony services to business customers. An example of an IP-based Virtual Private Network is disclosed in U.S. Pat. No. 6,693,878.
There are three types of VPN classified by the network layer used to establish the connection between the customer and provider network: Layer 1, VPNs, which are simple point-to-point connections using Layer 1 circuits such as SONET; Layer 2 VPNs (L2VPNs), where the provider delivers Layer 2 (L2) circuits to the customer (one for each site) and provides switching of the customer data; and Layer 3 (L3) VPNs (L3VPNs), where the PE device participates in the customer's routing by managing the VPN-specific routing tables, as well as distributing routes to remote sites. In a Layer 3 IP VPN, customer sites are connected via IP routers, e.g., provider edge (PE) and intermediate provider (P) nodes, that can communicate privately over a shared backbone as if they are using their own private network.
Each VPN is commonly associated with one or more VPN routing/forwarding instances (VRFs). A VRF defines the VPN membership of a customer site attached to a provider edge (PE) router. A VRF usually consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included into the routing table. Packet forwarding information is stored in the IP routing table and the forwarding table for each VRF. A VRF is only one type of VPN.
Multi-protocol label switching (MPLS) Border Gateway Protocol (BGP) networks are one type of L3VPN solution. MPLS-based VPNs use a Layer 3 connectionless architecture and a peer model that requires a customer site to only peer with one PE router as opposed to all other customer premises equipment (CPE) or customer edge (CE) routers that are members of the VPN. The connectionless architecture allows the creation of VPNs in Layer 3, eliminating the need for tunnels or virtual circuits (VCs). U.S. Pat. No. 6,665,273 describes a MPLS system within a network device for traffic engineering.
Virtual Private LAN Service (VPLS) has recently emerged as a L2VPN to meet the need to connect geographically dispersed locations with a protocol-transparent, any-to-any, full-mesh service. VPLS is an architecture that delivers Layer 2 service that in all respects emulates an Ethernet LAN across a wide area network (WAN) and inherits the scaling characteristics of a LAN. All customer sites in a VPLS appear to be on the same LAN, regardless of their locations. In other words, with VPLS, customers can communicate as if they were connected via a private Ethernet LAN segment. The basic idea behind VPLS is to set up a full-mesh of label switched paths (LSPs) between each PE router so that Media Access Control (MAC) frames received on the customer side can be switched based on their MAC addresses and then encapsulated into MPLS/IP packets on the P node side and sent across the VPLS domain over the full mesh. Conceptually, VPLS can therefore be thought of as an emulated Ethernet LAN segment connected by a set of virtual bridges or virtual Ethernet switches.
Digital Subscriber Line (DSL) technology is widely-used today for increasing the bandwidth of digital data transmissions over the existing telephone network infrastructure. In a typical system configuration, a plurality of DSL subscribers are connected to a service provider (SP) network through a Digital Subscriber Line Access Multiplexer (DSLAM), which concentrates and multiplexes signals at the telephone service provider location to the broader wide area network. Basically, a DSLAM takes connections from many customers or subscribers and aggregates them onto a single, high-capacity connection. The DSLAM may also provide additional functions such as routing or Internet Protocol (IP) address assignment for the subscribers.
In Metro Ethernet and DSLAM aggregation deployments, the scalability of VLANs and network services is a need that continues to grow among service providers (SPs) worldwide. One difficulty is how to scale point-to-point Ethernet Virtual Connections (EVCs) in Metro Ethernet networks. Currently service providers who need to offer broadband service to their subscribers can choose between two different primary architectures: IEEE 802.1Q (“QinQ”) tunneling architecture and MPLS network architecture with Ethernet over MPLS (EoMPLS) extended at the edge of the SP network.
In QinQ tunneling, the SP assigns a provider-VLAN tag for each service instance. This tag is used in the provider Ethernet switches to identify the customer's VLAN (CVLAN) across the core SP network. While QinQ allows an increase in the number of customers by carrying multiple customers' VLANs in a single SP VLAN, the services which can be offered are inherently limited by the available VLANs in the SP's Layer 2 domain. In other words, the proposed IEEE 802.1Q specification is limited by the fact that the 12-bit VLAN ID can only support a combined total of up to 4,094 broadcast domains and service instance domains. The 4K VLAN ID space thus restricts the number of VLANs or VPNs that can be handled, and is often inadequate for operations over a SP Metro network. One proposed solution to the scalability problem imposed by the 4K VLAN ID space limitation is described in U.S. Patent Application Publication 2004/0165600.
The main drawback of the MPLS network architectural approach with Ethernet over MPLS (EoMPLS) extended at the edge of the SP network is that it is much more expensive as compared to the QinQ approach. In addition, MPLS networks are generally not optimized for multipoint connection. This is due to various reasons, such as a lack of local switching (VLAN bridging) within the access network, traffic replication, and bandwidth consumption at the edge of the core. A pure MPLS architecture also does not allow VLAN bridging, which might be a requirement for certain SPs to interconnect end-users in the same Metro area.
Another possible architectural solution is the proposed IEEE 802.1ad standard, which defines a tunneling mechanism to scale the number of MAC addresses in a Layer 2 network. Basically, this approach improves the service scalability problem by introducing a 20-bit service instance identifier, thereby overcoming the 4,094 VLAN ID limitation discussed above. However, the problem with this approach is that the IEEE 802.1ad standard does not provide traffic engineering capability for point-to-point EVCs.
What is needed therefore is an apparatus and method that overcomes the aforementioned problems inherent in the prior art, and which is capable of offering a wide variety of services (e.g., voice, video, and data with L2 and L3VPN capability) on a single physical interface.